I'd like to make two minor observations:

(1) I'm not sure whether I've tested enough for this result to be significant but there appears to be a small but not negligible performance cost to this change on most snapshots (though I'm sure it does help greatly in pathological cases).

(2) This change is affecting at least one result in about half of the snapshots I tested, which is more than I expected. If it's supposed to affect only the most pathological cases, the threshold (10) could be much too low. On the other hand, if we think these results are confusing anyway, why isn't the number 2?

These things said, I'm quite happy with this change being in the release as-is.

(1) The lgtm.com dist was upgraded to deacc23 today, and that includes this PR. That means we can go explore lgtm.com to see if jump-to-definition seems to be working.

I picked this file arbitrarily and browsed through it. As far as I can tell, everything's in order. The only code without jump-to-def is macro arguments and code that's #ifdef'ed out.

(2) I agree that this PR was a temporary fix. Ideally, I see no reason the query should ever return more than one definition for a given use. That just means we store unnecessary data that'll be thrown away when the file is viewed because the viewer will pick arbitrarily among all the candidate definitions. It would be better to make this arbitrary choice in QL because (a) we know it'll be deterministic and (b) we can apply criteria such as preferring a definition in the current file over a definition in other files.